Summary

Refines the branded error-page experience so failure states stay polished, intentional, and easier to recover from.

Changes

• kept the active custom error handling centered on the ui layer
• removed the unused duplicate core/error_views.py module
• preserved lightweight error handlers that render branded templates for 403, 404, and 500
• refined the custom error-page templates to keep recovery actions consistent with the current product surface
• replaced the merchant-specific sign-in CTA on branded error pages with a more neutral sign-in entry point
• retained the shared product shell, explanatory messaging, and recovery guidance across all error states

Behavior

Error states now continue to render through the branded UI layer while offering a more neutral sign-in recovery path. Users still get the same clear explanation of what happened and a direct way back to a safe entry surface, but they are no longer funneled to a merchant-specific login route from generic error pages.

Why

This makes the error experience more consistent with the rest of the product and avoids implying that merchant login is the default recovery action for every failure state. It also removes duplicate error-view code so there is one clear active implementation.

Validation

The current implementation is aligned with the live project wiring:

• config/urls.py points error handlers at ui.error_views
• branded templates exist for:
  • templates/errors/403.html
  • templates/errors/404.html
  • templates/errors/500.html
• existing tests already target the ui.error_views implementation rather than the removed duplicate module

Result

ReturnHub now has cleaner custom error-page wiring and more appropriate recovery CTAs, while preserving the polished branded failure-state experience.

Notes

• this change affects error handling and error-page presentation only
• no business workflow logic or API behavior was changed
• the custom audit-export route remains unrelated to this work